Kicksecure Coding Style
Donate
Simplicity, Brevity, Sparingly Forking Upstream Projects, Feature Removability
stub[edit]
Documentation for this is incomplete. Contributions are happily considered! See this for potential alternatives.
Simplicity[edit]
For lack of better term, Kicksecure is simple. It does not fork or re-compile software packages by upstream projects.
Examples of software where it is often assumed that it is being modified by Kicksecure or being asked in that is the case:
- No good examples yet.
This has the advantage that questions and issues caused by upstream projects can be redirected upstream as per Self Support First Policy. This reduces the maintenance load at Kicksecure project.
Issues which cannot be caused by a Linux distribution are sometimes mistakenly attributed to that Linux distribution. Examples:
- https://www.mail-archive.com/qubes-users@googlegroups.com/msg29899.html
- https://www.mail-archive.com/qubes-users@googlegroups.com/msg29573.html
- https://forums.whonix.org/t/monero-and-whonix-15-0-1-5-1-bug/10532
Related: Relationship With Upstream
Brevity[edit]
In most cases goals should be reached by using 1 implementation. For example to remount /run etc. with more secure mount options an implementation should do this - if possible - either entirely in initramfs or entirely using systemd. It shouldn't do the exact same things twice in initramfs and systemd.
There’s a huge amount of things which users might potentially do which won’t make sense from Kicksecure developers point of view. For example there is the hello package which most users won’t know and won’t install. I am using it as an example here. No need to pick on that particular contributor of that Debian package. Why allow installation of that package? What if that contributor turned evil and somehow included a backdoor in the hello package? To prevent such a backdoor from doing damage, there could be an apt wrapper that prevents installation of that and other packages which most users will probably never need. I am not supposing to invent an apt wrapper for this hypothetical scenario. It would be worse having that code than having that risk.
Feature Removability[edit]
In case a feature becomes unmaintainable there needs to be a possiblity to remove the feature for users who use upgrade their system using apt.
No Trailing Whitespaces[edit]
Get a decent editor and don’t leave whitespace at the end of lines.
Indentation[edit]
Do not use too deep levels of if and similar.
Bad example:
machine_id() {
if ! test -f /etc/machine-id ; then
existing_machine_id="$(cat /etc/machine-id)"
## ...
fi
}
In above example there is need need to put everything under the if. This is specifically important when there are several levels of conditionals.
Example good:
machine_id() {
if ! test -f /etc/machine-id ; then
return 0
fi
existing_machine_id="$(cat /etc/machine-id)"
## ....
}
Shell Scripts[edit]
avoid sed awk whenever possible[edit]
There might be some older code (before introduction of str_replace) that uses sed / awk. Patches welcome to port to str_replace.
use str_replace whenever possible[edit]
str_replace is installed in Kicksecure by default. (man page) [1]
use type -P instead of which[edit]
Please do not use which. Please use type -P instead.
https://mywiki.wooledge.org/BashFAQ/081
Proper Whitespace Handling[edit]
See Dev/bash.
See Also[edit]
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2024 ENCRYPTED SUPPORT LP
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!